wrt 6aa3732 it's not that we stop to normalize the predicates of projections, it's that when comfirming alias-bound/Projection candidates, we required that the alias is well-formed. While we need to normalize these obligations before proving them, the normalize isn't the relevant part, the "we need to prove them at all" is.

wrt tests/ui/higher-ranked/trait-bounds/normalize-under-binder/norm-before-method-resolution-opaque-type.rs see https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/sizedness.20bounds.20in.20explicit_implied_predicates_of.20.28.23142712.29/near/526987384. It's intended that this test changes to be ambiguous.

tests/ui/generic-associated-types/issue-92096.rs fails to prove C::Connecting<'placeholder>: Send which is required when proving that the generator is Send. This is 'just' an instance of #110338

Did you already crater run this behavior?

Did you already crater run this behavior?

We did a crater run in #142712 (comment), which had all of these changes and included implying MetaSized on associated types.

Updated the README and corrected the descriptions of everything per your comment

Rebased following #143545

Nominated as per #t-types/nominated > #143992: where bounds regression in beta+nightly @ 💬

This PR does two relevant changes we need to FCP. We've already tried the first change before in #92191 and then reverted the PR as this caused a regression. The second change is necessary to avoid this regression and is also generally desirable.

Sized and auto trait goals now prefer alias-bound candidates over where-bounds

See #132325 for our existing candidate preference rules. We currently prefer where-bounds over alias-bounds for all candidates. This preference (like all preference) is arbitrary to some degree.

We need to do this for the following example:

trait Bound<'a> {}
trait Trait<'a> {
    type Assoc: Bound<'a>;
}

fn impls_bound<'b, T: Bound<'b>>() {}
fn foo<'a, 'b, 'c, T>()
where
    T: Trait<'a>,
    for<'hr> T::Assoc: Bound<'hr>,
{
    impls_bound::<'b, T::Assoc>();
    impls_bound::<'c, T::Assoc>();
}

We need to do so when normalizing:

trait Iterator {
    type Item;
}
trait IntoIterator {
    type Item;
    type IntoIter: Iterator<Item = Self::Item>;
}

fn normalize<I: Iterator<Item = ()>>() {}
fn foo<I>()
where
    I: IntoIterator,
    I::IntoIter: Iterator<Item = ()>,
{
    // normalizing `<I::IntoIter as Iterator>::Item` has two candidates:
    // - alias-bound normalizing to `<I as IntoIterator>::Item`
    // - where-bound normalizing to `()`
    normalize::<I::IntoIter>();
}

However, arbitrary candidate preference is a mess, so this is sometimes incorrect, either if the where-bound actually talks about a different alias, or different trait arguments:

trait Bound<'a> {}
trait Trait<'a> {
    type Assoc: Bound<'a>;
}

fn impls_bound<'b, T: Bound<'b>>() {}
fn foo<'a, 'b, T>()
where
    T: for<'hr> Trait<'hr>,
    <T as Trait<'b>>::Assoc: Bound<'a>,
{
    // Using the where-bound for `<T as Trait<'a>>::Assoc: Bound<'a>`
    // unnecessarily equates `<T as Trait<'a>>::Assoc` with the
    // `<T as Trait<'b>>::Assoc` from the env.
    impls_bound::<'a, <T as Trait<'a>>::Assoc>();
    // For a `<T as Trait<'b>>::Assoc: Bound<'b>` the self type of the
    // where-bound matches, but the arguments of the trait bound don't.
    impls_bound::<'b, <T as Trait<'b>>::Assoc>();
}

While figuring out whether where-bounds or alias-bounds have correct trait arguments isn't possible in general, we do know that alias-bound candidates always apply to exactly the right self type - the alias itself.

This means that in cases where the trait doesn't have any non-self parameters, prefering alias-bound candidates over where-bounds is always correct.

There is one edge case here, since #120752 we may also get alias-bound candidates from a nested self-type, so prefering alias-bound over where-bound candidates can be incorrect:

trait OtherTrait<'a> {
    type Assoc: ?Sized;
}

trait Trait
where
    <Self::Assoc as OtherTrait<'static>>::Assoc: Sized,
{
    type Assoc: for<'a> OtherTrait<'a>;
}

fn impls_sized<T: Sized>() {}
fn foo<'a, T>()
where
    T: Trait,
    for<'hr> <T::Assoc as OtherTrait<'hr>>::Assoc: Sized
{
    impls_sized::<<T::Assoc as OtherTrait<'a>>::Assoc>();
}

To avoid this issue, I propose limiting the preference of alias-bound over where-bound candidates only to the alias self-bounds, not indirect ones.

It also feels weird to me to implicitly change candidate preference depending on whether your trait has any generic arguments, so I propose to only change the preference rules for traits which are already special and guaranteed to not have any non-self arguments: Sized and auto traits.

To sum it up: we change our candidate preference rules to prefer alias self-bound candidates over where-bounds for Sized and auto traits. We continue to prefer where-bounds over alias bounds from nested self types and for all other traits.

Stop proving alias where-bounds when using alias-bounds

We currently prove the where-bounds of aliases when using an alias-bound candidate. This is generally redundant. We should have already proven these when checking whether the alias is well-formed.

However, we may have only ever proven well-formedness while the alias was still higher-ranked. If we then prove their where-bounds after instantiating this binder with placeholders, we get spurious errors due to missing implied bounds.

trait Bound {}
impl<'a, T> Bound for &'a T {}
trait Trait {
    type Assoc<'a>: Bound
    where
        Self: 'a;
}
impl<T> Trait for T {
    type Assoc<'a>
        = &'a T
    where
        Self: 'a;
}

// Using a higher ranked where-bound to prove itself succeeds,
// we don't check does not check whether it's WF after we've
// instantiated it. However, as normalizing an alias also requires
// proving its where-bounds, this function can only be called
// with types which are `'static`.
fn prove_hr<T: Trait>()
where
    for<'a> T::Assoc<'a>: Bound,
{
    prove_hr::<T>(); // ok
}
fn via_alias_bound<T: Trait>() {
    prove_hr::<T>(); // err, requires `T: 'static`, will compile with this PR
}
// Normalizing an associated item always checks its where-bounds.
fn via_impl_err<T>() {
    prove_hr::<T>(); // err, requires `T: 'static`
}

Ignoring the implied bounds of binders is generally unsound, e.g. #25860 and #84591.

The question is whether ignoring these implied bounds when using alias-bound candidates introduces any additional exploitable unsoundnesses:

• This only enables us to prove a where-bound whose self type is a higher-ranked alias
• To actually use this higher-ranked where-bound we need to instantiate the alias, at which point we should end up proving WF. As trait and alias parameters are all invariant, we can't hide erase the implied bound as in Implied bounds on nested references + variance = soundness hole #25860.
• I cannot think of an alternative way to use this alias-bound in a bad way. I've spent a few hours playing with this and wasn't able to come up with an exploit

cc @steffahn would love for you to also take a look at this if you're interested. We already have the behavior of this PR with -Znext-solver.

I am not totally confident that it's impossible to exploit this in theory, even though it feels unlikely to me. However, I do feel quite confident that any such exploit will be highly artificial and will get fixed once we properly support implied bounds for the existing unsoundnesses without requiring any additional effort or consideration.

I personally think that checking WF of the alias when using its implied bounds feels somewhat arbitrary and am in favor of removing this check.

@rfcbot fcp merge

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.